Mike: Welcome folks, it's time to take a look
at data security.
When designing your blob storage solution,
it's crucial to classify your data
based on its sensitivity level.
You can use tags
and metadata to categorize blobs as public, internal,
confidential, or restricted,
or if you have an industry standard, you would use that.
This allows you to apply appropriate security controls
based on the data sensitivity.
Azure Blob Storage offers several replication options
to ensure data durability and high availability.
As you've seen before, if you've taken previous lessons,
there's the locally redundant storage,
zone redundant, geo-redundant and read access geo-redundant,
not to mention the combination of geo and zone together.
Understanding these replication options is key
for designing disaster recovery
and high availability strategies to both meet the needs
for the customer and also minimizing
the costs to the customer.
Immutable blob storage, it allows for a write once,
read many or WORM policies.
You can set time-based retention policies
or legal holds to prevent data
from being modified or deleted,
common in different types of industries.
It's particularly important
for meeting regulatory requirements
and ensuring data integrity.
One of the things that you will encounter in industry
and in the exam is a scenario
that states specific regulatory requirements
that will be both your keynote in the case
of the exam, or an important factor in industry
as to where you configure things like immutable blob storage
and your other security access.
Speaking of which,
shared access signatures best practices.
You want to make sure
that there are short expiration times whenever possible.
Prefer stored access policies over ad hoc SAS.
Make sure that you use minimum required permissions.
Do not create access signatures
that grant more permissions than are necessary.
Enable HTTPS only
so that you are ensuring encryption in transit
when things are accessed
and regenerate your SAS keys periodically
to ensure that stale ones or ones
that have been used too long do not have the opportunity
to go out into the wild and be found by someone else.
Encryption for blob storage.
Well, it's essential obviously for protecting data at rest
and in transit, but encryption at rest
with Microsoft managed or customer managed keys is possible.
You can enable encryption in transit by enforcing HTTPS
for all API interactions,
and be sure to understand the encryption options
and key management responsibilities.
When you're using Microsoft managed keys,
there are certain types of responsibilities for your keys.
When you are providing
or managing those keys yourselves,
you are taking on different types of responsibility,
including the management
and recycling of those keys over time.
An important note here is to make sure
that secure transfer is required.
You can do this by enforcing HTTPS for all interactions,
as we mentioned, and to reject requests over HTTP,
and it's important to understand the secure transfer options
and configuration because whenever possible,
you do want to have your data encrypted in transit.
Again, it sounds like we're repeating this often,
but it is a common thing asked about on the exam
when these types of storage questions arise,
and even more importantly in industry.
There is rarely a time when you want storage data
to be transferred unencrypted,
especially in this new era of cyber warfare
that is constantly going on.
Firewall and virtual network rules.
Azure blob storage supports network level security
through firewall and virtual network rules.
You can choose to allow or deny public access
and restrict access to specified virtual networks.
This adds an additional layer of security
to your storage account, so it's important
to understand the network level security options
that you have available.
For even more secure network connectivity,
you can use private endpoints or service endpoints.
Private endpoints allow you
to connect blob storage privately from your virtual networks
while service endpoints
extend your virtual network's security to storage account,
and again, understand private
and service endpoint configuration and use cases.
So let's look at a scenario to try
to bring all of this together.
Suppose a customer needs
to store sensitive financial data in blob storage.
That data must be encrypted accessible
only from their virtual network
and protected against accidental deletion.
To meet these requirements, you can use blob storage
with a private endpoint for VNet access only,
enable encryption at rest with customer managed keys,
configure immutable blob policies to prevent deletion
and use read access geo-redundant storage
for geo redundancy and high availability.
This demonstrates how to combine multiple security controls
to design a secure blob storage solution.
I hope this has helped bring
some of these concepts into focus,
and I hope to see you in the next lesson.